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^= (54) Title: METHOD OF KEY EXCHANGE FOR A CRYPTOGRAPHIC SECURE POINT TO MULTIPOINT CONNECTION 

B (54) Bezeichnung: VERFAHREN ZUR SCHLtJSSELVEREINBARUNG FOR EINE KRYPTOGRAPHISCH GESICHERTE 
= PUNKT-ZU-MULTIPUNKTVERBINDUNG 



(57) Abstract: The invention relates to a method of Icey exchange for a cryptographic, secure, point to multipoint connection. The 
^ aim of the invention is to describe a universal method, which may be applied to existing transmission concepts and security archi- 
\1 tectures with as little modification as possible, and can, in particular, be patched into the OSI layer model without problems. Said 
^ aim is achieved with a method, whereby the key exchange occurs by a modified SSL- or TLS-protocoL The sequence of messages 

in the handshake which introduces the SSL session are thus altered according to a code in a server message, which characterises the 
1/^ connection to be made as an IP multicast connection. 

^ (57) Zusammenfassung: Die Erfindung betriflft ein Verfahren zur Schllisselvereinbarung fUr eine kryptographisch gesicherte 
Punkl-zu-Multipunklverbindung. Ihr liegt die Aufgabe zugrunde, ein universelles Verfahren anzugeben, welches so wenig wie 

2 mdglich vcrandemd in bcreits bcstchende Dbertragungskonzcpte und Sicherhcitsarchitekturen eingrcift und sich insbesondere 
problemlos in das OSI-Schichtenmodell einfUgt. Die Aufgabe wird geldst durch ein Verfehrcn, bei dem die Schlttsselvercinbarung 

Q nach einem modifizierten SSL- bzw. TLS-ProtokoU erfolgt. Dabei wird in AbhSngigkeit eines in einer Server-Nachricht enthaltenen 

^ Kennzeichens. welches die aufzubauende Verbindung als IP Multicast- Verbindung kennzeichnet. die Reihenfolge der Nachrichten 

^ des die SSL-Sitzung einleitenden Handshakes verSndert. 
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Verfahren zur Schliisselvereinbarung fur eine kryptographisch gesicherte 
Pimkt-zu-Multipiuiktverbinduiig 

S Die Erfindung betrifft ein Ver&hren zur Schlusselverdnbarung fur eine kryptographisch 
gesicherte Piinkt-zu-Midtipimktv«bindung. Sie schlagt eine Losung vor, bei welcher von 
Punkt-zu-Punktverbindungen bekannte Prinzipien der Schlusselvereinbarung fur eine 
gesicherte Datenubertragung zwischen einem Client und einem Server in* geeigneter 
Weise fur den Aufbau einer Multicast-Verbindung modifiziert werden. 

10 Mit der zunehmenden Nutzung des Internets stdgt auch die Gefahr eines Missbmuchs 
und/oder einer Manipulation der Vielzahl der ub^ das Netz ausgetauschten, teilweise 
sensiblen Daten. Die Mehiheit der Nutzer des Internets und selbstverstandlich erst recht 
die Fachleute sind der Tatsache bewusst, dass das Internet insoweit als eine unsichere 
Umgebung anzusehen ist. Urn aber dennoch die Nutzungsmoglichkeiten des Internets zu 

15 erhohen, steigt aus den vorgenannten Grunden der Bedarf an Losungen fiir eine 
vertrauliche Datenubertragung. Es werden Losungen benotigt, welche die Vertraulichkeit, 
die Integritat und die Authentizitat von Daten gewahrleisten. Aufgrund der technischen 
BeschafFenheit des Internets als ein fiir jedermann ofFenes Netz, kommt eine Sicherung 
der Daten in der Form einer physikalischen Zugangssperre fur schiitzenswerte Daten nicht 

20 in Betracht. Die Losung des Problems besteht daher darin die uber das Netz geleiteten 
Daten, zumindest soweit es sich um sensible Daten handelt oder aber sogar generell, zu 
verschlussehi und im Zuge dieser Verschlusselung durch geeignete Verarbeitung der 
Daten Mexkmale zum Nachweis ihrer jeweiligen Authentizitat zu gewinnen. 
Zur Absicherung von Client-Server-Verbindung sind hierzu bereits unterschiedliche 

25 Ansatze bekannt geworden. Ein inzwischen relativ weit verbreitetes Verfahren zur 
Schlusselvereinbarung bei Verbindungen, die einen gesicherten Datenaustausdi zulassen, 
ist das so genannte Secure Sockets Layer-ProtokoU (SSL), welches in seiner 
standardisiertra Variante auch als Transport Layer Security (TLS) bekannt ist Dieses 
ProtokoU regelt die Modalitaten fiir eine Verbindung zwischen einem Client und einem 

30 Server bei der die Daten in versddusselter Form ubertragen werden. Mit Hilfe des 
Protokolls verstandigen sich der Client und der Serv^ uber das zu vowendende 
Verschliisselungsverfahren, die wahrend des Bestehens der Verbindung zur 
Verschlusselimg eingesetzten Sitzungsschliissel, uber Authentizitatsmerkmale sowie 
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gegebenenfells uber weitere Verbindungsmodalitaten, wie bdspielsweise Verfahren zur 
VerringOTing des Dateavolumens diirch Datenkompression. Der Vorteil des Verfahrens 
ist dabei darin zu sehen, dass sich das SSL-Protokoll nahtlos in das OSI-Schicht^imodell 
fur den Datenteuisfer einfugt. Insoweit stellt das ProtokoU emen in bdden Richtungen 
5 transparenten Ubergang (Socket) vorzugsweise zwischen desr Anwendungs- und 
Transportschicht entsprechend dem Schiditenmodell dar. Das SSL-Protokoll wird 
beispielsweise naher erlautert durch Steph^ Thomas in ,,SSL & TLS Essential'^ John 
Wiley & Sons, New York 2000. Auf das Protokoll wird spater im Zusammenhang mit der 
Eriauterung der Erfindung noch naher einzugehm sein. 

10 Wie dargestellt, wurde SSL/TLS zur Absicherung von Punkt-zu-Punkt-V^bindungen 
konzipiert. Dies wird unter anderem auch daran deutlich, dass zwei d&c drei Werte 
(PremasterSecret, ClientRandom), aus denen letztlich der kryptographische Schlussel 
abgeleitet wird, vom Client generiert werdm. Es ist daher nicht moglich, dass der Server 
in der Kommunikation mit verschiedenen CUents jeweils den gleichen Schlussel 

15 verwendet. Diese Tatsache macht den Einsatz des SSL-Handshakes, wie er vom 
standardisierten SSL-Protokoll bekannt ist, in Punkt-zu-Multipunktverbindungen mit dem 
Server als Datenquelle und mehreren Clients als Datensenken unmoglich. Derartige 
IP Multicast- Veibindungen ermoglichen bei einer Vielzahl von Anwendungsfallen eine 
effektive Ausnutzung der im Netz zur Verfiigung stehenden Bandbreite und ingesamt 

20 einen sparsamen Umgang mit Zeit- und Hardwareressourcen. Sie werden beispielsweise 
beim Streaming von Audio- Videodaten eingesetzt. Selbstverstandlich besteht aber auch 
hier der Bedarf an gegen Missbrauch und Manipulation gesicherten Verbindungen. In 
diesem Zusammenhang sind aber bisher nur proprietare Losungen, wie beispielsweise im 
Zusammenhang mit dem DVB (Digital Video Video Broadcast) bekannte geworden, 

25 welche ab«: nicht ohne weiteres fur andere Zwecke einsetzbar sind, 

Der Erfindung liegt daher die Aufgabe zugrunde, ein universelles Verfahren zur 
Schlusselverembarung fur eine kryptographisch gesicherte Punkt-zu- 
Mulitpunktverbindung anzugeben. Zudem soil das Verfahren so wenig wie moglich 
30 verandemd in bereits bestehende Ubertragungskonzepte und SichCTheitsarchitekturen 
eingreifen, sich aber insbesondere problemlos in das OSI-Schichtenmodell dnfugen. 
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Die Aufgabe wird durch ein Verfahren mit den Merkmalen des Hauptanspruchs gelost 
Vorteilhafte Ausgestaltungen bzw. Weiterbildungen des erfindungsgemSBen Verfahrens 
sind durch die Unteranspriiche gegeben. 

Gemafi der Erfindung erfolgt die Schlusselvereinbarung wahrend des Aufbaus der 
5 Verbindung zunachst in Anlehnung an das SSL- bzw. XLS-ProtokoU, wobei jedoch in 
Abhangigkeit eines in einer Server-Nachricht enfhaltenen Kennzeichens» welches die 
au&ubauende Verbindung als IP Multicast-Verbindung kainzeichnet, die Reihenfolge der 
Nachrichten des die SSL-Sitzung einleitenden Handshakes verandert wird. Gleichzeitig 
wird d^ zur Erzeugung des oder der Sitzungsschlussel fur die Verschlusselung der 

10 Anwendungsdaten dienende MasterKey vom Server generiert. Der vom Server generierte 
MasterKey wird dann gegebenenfalls mit dem offentlichCT Schlussel des Clients 
verschlusselt an den Client ubertragen. Ob eine Verschlusselung des MasterKey mit dem 
dffentlichen Schlussel des Clients erfolgt hangt dabei von der konkret gewahlten 
Verfahrensvariante ab, wobei die Verfahrensvarianten, welche Gegenstand von 

15 Ausgestaltungen des erfindungsgemaUen Verfahrens sind, nachfolgend noch erlautert 
werden. Die Ubertragung des MasterKey an den Client erfolgt mittels einer im weiteren 
als ServerMasterKeyExchange-Nachricht bezeichneten Nachricht. Diese Nachricht 
unterscheidet sich von der in manchen Darstellungen des Standard-SSL verwendeten 
ServerKeyExchange-Nachricht. Mit der letztgenannten Nachricht gibt der Server dem 

20 Client beim Standard-SSL seinen offentlichen Schlussel (unverschliisselt) bekannt. Dieser 
offentUche Schlussel wird daim spater vom Client zur Verschlusselung des von ihm 
generierten und an den Server iibertragenen MasterKey verwendet. Im Gegensatz dazu 
handelt es sich bei dem gemaB der Erfindung mit d^ ServerMasterKeyExchange- 
Nachricht ubertragenen Schlussel urn den MasterKey zur Ableitung der weiteren 

25 Sitzungsschlussel, welcher also abwddiend vom Standard-SSL vom Server und nicht 
vom Client erzeugt und zur Verwendung in der jeweiligen Sitzung zur Verfiigung gestellt 
wird. Daher wird diese Nachricht zur Venneidung von Missverstandnissen im weiteren 
als ServerMasterKeyExchange-Nachrichtbezeidmet. 

Entsprechend einer mSglichen Ausgestaltung des erfindungsgemafien Verfahrens ist das 
30 zur Kennzeichnung der Verbindung als IP Multicast-Verbindung dienende Kennzeichen 
(IP Multicast-Kennzeichen) Bestandteil des vom Server mit der 
CertificateRequest-Nachricht angeforderten ClientCerficateType. 
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Eine andere Variante des Verfahrens sieht die Au&ahme einer anderen neuen, fiir die 
praktische Umsetzung der ErfinduBg noch zu definierenden Naduicht des S^ers in das 
Handshake-ProtokoU vor Hieibei handelt es sich quasi um dne modifizierte 
ServerMasterKeyExchange-Nachricht, mit welcher der Server den von ilim graeriertm 
5 MasterKey und, je nach weiterer Ausgestaitung dieser Variante, dn die Veibindimg als 
IP Multicast- Verbindung charakterisierrades Kennzeidien an den Client ubermittelt. 
Prinzipiell besteht also die Moglichkeit, dass das IP Multicast-Kennzeichen boreits mit 
der CertificateRequest-Nachricht des Servers ubertragen wird oder aber erst spater als 
Bestandteil der schon genaraiten modifizierten ServerMasterKeyExchange-Nachricht Da 

10 sich allerdings im letzgenannten Fall Probleme hinsiditlich der Abwartskompatibilitat 
zum Standard-SSL ergeben (der Client geht bis zum Empfang der modifizierten 
ServerMasterKeyExchange-Nachricht von einem Ablauf nach dem Standard-SSL- 
Handshake aus und kaim so unter Umstanden mit der fur ihn fremden modifizierten 
ServerMasterKeyExchange-Nachricht nichts anfangen), ware der ersten Variante der 

15 Vorzug zu geben. 

Bei der Einfugung des IP Mxilticast-Kemizeichens in die CertificateRequest-Nachricht 
gestaltet sich ein mogliches Verfahrensregime wie folgt. Nachdem der Client die mit dem 
IP Multicast-Kennzeichen versehene CertificateRequest-Nachricht vom Server 
empfangen hat, wird der Ablauf des die SSI^Sitzung einleitenden Handshakes zunachst 

20 in der Weise verandert, dass die Generierung des MasterKey durch den Client unterbleibt. 
Der Client setzt sein Certificate ab, ohne, wie sonst dem SSL-Handshake entsprechend, 
unmittelbar daran anschliefiend eine ChangeCipherSpec-Nachricht sowie eine 
Finished-Nachricht auszusenden und auf verschlusselte Ubertragung umzusdialten. Nach 
dem Empfang des Certificate des Clients gibt der Server eine ServerMasterKeyExchange- 

25 Nachricht aus. Diese Nachricht bemhaltet den MasterKey bzw, das MasterSecret, aus 
dem im weiteren Ablauf die Sitzungsschlussel abgeleitet werden. Unmittelbar nach 
Ausgabe der ServerMasterKeyExchange-Nachricht sendet der Server ChangeCipherSpec 
und daran anschliefiend Finished. Der Client bestatigt den Empfang der 
ServerMasterKeyExchange-Nachricht, indem er seinerseits ChangeCipherSpec und 

30 Finished ausgibt sowie in den Modus fur verschlusselte Ubertragung umschaltet Hieran 
anschliefiend kann die eigentliche unter Verschliisselung der Daten ablaufende Sitzung 
beginnen. Genauso wie beim Standard-SSL-Protokoll erfolgt bei dieser 
Verfahrensvariante der Schlusselaustausch, namlich die Ubennittlung des Masterkey fiber 
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den zunachst noch ungesicherten Kanal. Dies ist aber insoweit xmproblematisch als der 
Masterkey bei dieser Verfahrensvariaiite mit detn dffentlichen Schlussel des Client 
verschliisselt ist. 

GemaB einer anderen Variante des mit der Erfindung vorgeschlagenen VCTfahrens erfolgt 
5 der Austausch des MasterKey der zur Ableitung der Schlussel fur die eigentUche Sitzung 
dient, uber einen bereits SSL^/TLS-gesicherten Kanal. Der Verfabrensablauf gestaltet sich 
folglich etwas anders. Zunachst lauft der Handshake bis zur ChangeCipherSpeo- 
Nachricht des Servers entsprechrad dem Standard SSL-ProtokolI ab. Erst hiemach wird 
der weitere Ablauf modifiziert. Umnittelbar der ChangeCipherSpec-Nachricht folgend 

10 gibt dabei der Server eine neue, bei einer etwaigen Au&ahme in den Standard in der 
Praxis noch exakt zu definierende Nachricht aus. Es handelt sich hi^ei quasi um eine 
modifizierte ServerMasterKeyExchange-Nachricht Bestandteile dieser Nachricht sind in 
jedem Falle ein neuer vom Servo: generierter MasterKey und gegebenenfalls ein die 
Umschaltung des Ablaufs bewirkendes IP Multicast-Kennzeichen. Da der Client und der 

15 Server aufgrund von ihnen bereits ausgegebener C3hiangeCipherSpec-Nachrichten bereits 
im verschliisselten Modus arbeiten, kann bei dieser Verfahrenskonstellation der 
MasterKey ohne weitere Verschlusselung mit dem offentlichen Schlussel des Clients 
ubertragen werden. Der Client antwortet hierauf mit einer emeuten ChangeCipherSpec- 
Nachricht sowie der emeuten Ausgabe der Finished-Nachricht. Daran schliesst sich dann 

20 die nochmalige Ausgabe von ChangeCipherSpec und Finished durch den Server an. 
Client und Server schalten in diesem Fall mit der Ausgabe der Finished-Nachricht in 
einen Modus zur Verschlusselung der Daten xmter Verwendung des neuen MasterKey 
um. 

Die Erfindung ist besonders vorteilhaft ausgestaltet, wenn der Server jeweils in der 
25 Kommunikation mit einem Client die gleiche CipherSuite verwendet, die er zuvor in der 
Kommunikation mit anderen Clients dem Handshake zugrunde gelegt hat Wenn diese 
CipharSuite in der ClientHello-Nachricht nicht entfaalten ist, wird zweckmaBigerweise 
eine Fehlermeldung durch den Server ausgegeben. Die zuletzt dargestellte Variante, 
welche bis zur erstmaligen Ausgabe der ChangeCipherSpec-Nachricht durch den Server 
30 nach dem Standard-SSL-ProtokoU ablauft, ist besonders vorteilhaft ausgestaltet, wenn der 
Server beim zweiten ChangeCipherSpec die gleiche, auch als gemeinsame CipherSuite in 
der Kommunikation mit den and^en Clients dienende CipherSuite beibehalt 
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Die Erfindung soli nachfolgend an Hand von Ausfuhrungsbeispielen naher erlautert 
werden. Zum besseren Verstandnis soil dazu zunachst der SSL-Handshake nach dem 
Standaid-SSL-Piotokoll kurz orlantert werden. Der Handshake gestaltet sich nach dem 
folgenden Ablauf, welcher in der Fig. 2 aucb nochmals in einer Blockdarstellung gezeigt 
5 ist: 



CUent 



Server 



ClimtHello-Nachricht mit den 
10 vorgeschlagenen SSL-Optionen 



15 



Certificate-Nachricht mit Clientzertifikat 
20 ClientKeyExchange-Nachricht mit 

Sitzungsschlussel (verschlusselt mit 

Public-Key des Servers) 

CertificateVerify-Nachricht mit Signatur 

aller vorangegangenen Handshake- 
25 Nachrichten 

ChangeCipherSpec 

Finished 



30 



ServerHello-Nachricht mit den aus- 
gewahlten SSL-Optionen 
Certificate-Nachricht mit 
Serverz^fikat 

CertificateRequest-Nachricht, der 
CUent wird aufgefordert, sich zu 
authentifizieren 
ServerHelloDone-Nachricht 



ChangeCipherSpec 
Finished 



Die SSL-Sitzung beginnt mit dem ClientHeUo des Client Hierauf antwortet der Server 
mit einer S^erHello-Nachricht nnd gibt anschliefiend dem Client sein Certificate 
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bekannt. Bestandteil des mit der ServerHello-Nachricht eingeleiteten ServerHello-Blocks 
ist auBerdem eine CertificateRequest-Nachricht Hiennit fordert der Server den Clieat 
auf, sich zu authentifizieren. Der ServerHeUo-Block wird dutch die ServerHelloDone- 
Nachricht abgeschlossen. Der Client authentifiziert sich beim Server mittels einer 
5 Certificate-Nachricht und einer nachfolgend noch zu erlautemden C^ficateVerify- 
Nachricht Nach der CertijScate-Nachricht wird jedoch vom Client zunachst eine 
ClientKleyExchange-Nadiricht ausgegeben. Mit dieser Nachricht teilt der Client dem 
Server den mit dem PublikKey des Servers verschlusselten MasterKey mit, welcher im 
weiteren Verlauf der Ableitung der Sitzungsschlussel entsprechend dem zwischen Client 

10 und Server vereinbartea Verschlusselungsverfahren dient An die ClimtKeyExchange- 
Nachricht des Clients schlieBt sich dann die CertificateVerify-Nachricht an, mit welcher 
der Client die vorangegangenen Handshake*Nachricht^ signiert. Zur Beendigung des 
Handshake wird durch den Client ChangeCipherSpec sowie Finished ausgegeben und 
daran anschlieBend unmittelbar in den Modus zur verschlusselten Ubertragung 

15 umgeschaltet. Der Server quittiert dies seinerseits mit ChangeCipherSpec und Finished 
und schaltet ebenfalls in den Modus zur Ubertragung verschliisselter Daten um. 
Wie aus dem dargestellten Ablauf zu ersehen ist, wird der MasterKey zur Ableitung der 
weiteren Sitzungsschlussel durch den Client generiert Zwei der drei Werte, namlich das 
PremasterSecret und das ClientRandom werden dabei vom Client zur Verfugung gestellt. 

20 Selbstverstandlich kann der vom Client gelieferte MasterKey daher nicht fur die 
Kommunikation mit anderen Clients verwendet werden. Hier setzt die Erfindimg an, Sie 
geht von der Uberlegung aus, einer der vom Server ausgegebenen Nachrichten ein 
IP Multicast-Kemizeichen hinzu zu fiigen und hierdurch den Ablauf des Handshake* 
ProtokoUs zu modifizieren sowie zu veranlassen, dass der MasterKey in Folge dieses 

25 modifizierten Ablaufs nicht durch den Client, sondem durch den Server generiert wird. 
Hierfur konnte sich der Handshake gemaB einer ersten Variante des erfindungsgemaBen 
Verfahrens, welche durch die Fig. 1 nochmals in eui^ Blockdarstellung veranschaulidit 
ist, wie nachfolgend angegeben gestalten. 

30 Client Server 



ClientHeUo 



ServerHello 
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Certificate 
CertificateVerify 



10 



ChangeCipherSpec 
Finished 



4- 



4- 



C^ficate 
CertificateRequest 
ClientCertificateType: Multicast 
(z.B. 30) 

ServerHeUoDone 



ServerMasterKeyExchange 

ChangeCipherSpec 

Finished 



Zunachst wkd zum Beguin der Sitzung wie beim Standard-SSL-Protokoll durch den 

15 Client eine ClientHello-Nachricht an dea Server ubennittelt. Der Server antwortet 
eben£dls, noch d^ standardisierten Ablauf folgend, mit einer ServerHello-Nachricht. 
Der ServerHello-Nachricht folgt eine Certificate-Nachricht Die darauf folgend 
ausgegebene CertificateRequest-Nachricht beinhaltet in der Form des 
ClientCertificateType ein die aufeubauende Verbindnng als IP Multicast-Verbindung 

20 charakterisierendes Kennzeichen, in d^ Beispiel durch die Zahl 30 gekennzeichnet. 
Durch dieses IP Multicast-Kennzeichen wird dem Client signalisiert, dass der SSL- 
Handshake im weiteren in einer etwas modifizierten Form, insbesondere mit Veranderung 
der Reihenfolge der Nachrichten ablauft. Der mit der ServerHello-Nachricht eingeleitete 
imd das Certificate sowie das CertificateRequest mit dem IP Multicast-Kennzeichen 

25 enthaltende ServerHello-Block wird durch die ServerHelloDone-Nachricht 
abgeschlossen. Der Client gibt entsprechend der Aufforderung durch die 
CertificateRequest-Nachricht sein Certificate bekannt. Dieses Certificate muss ein 
Kennzeichen enthalten, welches den Client dafiir authentisiert, in einer IP Multicast- 
Verbindung Daten mit dem Server auszutauschen. Anders als beim Handshake ProtokoU 

30 nach dem Standard-SSL wird jedoch durch den Client nach der Ausgabe der Certificate- 
Nachricht keine ClientKeyExchange-Nachricht abgesetzt. Es werden lediglich die zuvor 
ausgesendeten Nachrichten durch das CertificateVerify signiert Auch die Ausgabe einer 
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ChangeCipherSpec-Nachricht sowie des Finished unterbleibt zunachsL Vielmehr werdea 
nun zunachst durch den Server eine Reihe von Nachrichten ausgegeben. Zunachst setzt 
der Server eine ServerMasterKeyExchange-Nadmcht ab. Diese Nachricht beinhaltet den 
von ihm generierten und mit dem dffentlichen Schlussel des Clients verschlusselten 
5 MasterKey. Die Grundlage zur Ableitung der fur die VerscMusselung der Nutzdaten 
benStigten Sitzungsschlussel bildet also abweichend vom Standard SSL der vom Server 
erzeugte MasterKey. Nach der Ausgabe der ServerMasterKeyExchange-Nachricht setzt 
der Server noch ChangeCipherSpec sowie Finished ab und schaltet danach in den Modus 
fur eine verschlusselte Ubertragung um. Erst hiemach gibt der Client seinerseits 

10 ChangeCipherSpec sowie Finished aus und schaltet ebenfalls in den Modus zur 
Verschlusselung der Daten rnn. Abweichend von dem Handshake nach dem 
Standard-SSL-ProtokoU wird also die Einleitung der eigentlichen, verschlusselt 
stattfindenden Sitzung nicht durch das Finished des Servers sondem diirch das Finished 
des Clients abgeschlossen. 

15 Eine andere Verfahrensvariante ist dadurch gegeben, dass der zur Erzeugung der 
Sitzungsschlussel fiir dieVerschliisselxmg der eigentlichen Nutzdaten dienende MasterKey 
bereits uber einen SSL-gesicherten Kanal iibertragen wird. Ein moglicha: Ablauf des 
Handshake gestaltet sich dann wie folgt. 

20 Client Server 

ClientHello -> 

<- ServerHello 
Certificate 

25 <- CertificateRequest 



ServerHelloDone 



Certificate 

ClientKeyExchange-Nachricht 
CertificateVerify -> 
30 ChangeCipherSpec 
Finished 



<- ChangeCipherSpec 
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modifizierter 

ServerMasterKeyExchange 
IP-Multicast-Adresse bzw. 
K^mzeichen 
IP-Multicast-Schlussel 

ChangeCipherSpec 

Finished 



ChangeCipherSpec 
Finished 



10 



Der Handshake verlauft bis zur Ausgabe der ersten ChangeCipherSpec-Nachricht durch 
den Server entsprechend dem Standard-SSL-ProtokoU. Der Server reagiert hierauf mit 
einer ChangeCipherSpec-Nachricht, die aber abweichend vom iibUchen Ablauf nicht 
durch die Finished-Nachricht gefolgt wird. Start dessen gibt der Server nun eine fur die 

15 praktische Umsetzung der Erfindung noch naher zu definierende Nachricht aus. Diese 
enthalt zumindest einen vom Server generierten MasterKey und soil daher hier im 
weiteren als modifizierte ServerMasterKeyExchange-Nachricht bezeichnet werden. Die 
genaue Ausgestaltung dieser Nachricht hangt davon ab, zu welchem Zeitpunkt getnafi 
dieser zweiten Variante das IP Multicast-Kennzeichen vom Server an den Client 

20 Qbemiittelt wird. Das IP Multicast-Kennzeichen kann dabei wie bei der Variante 1 
Bestandteil der CertificateRequest-Nachricht des Servers sdn oder aber entsprechend 
dem vorstehend dargestelltm Ablauf einen Teil der modifizierten 
ServerMasterKeyExchange-Nachricht bilden. Bin anderer, nochmals geringfugig 
modifizierter Ablauf gestaltet sich entsprechend dem folgenden Schema. 

25 CKent Server 

ClientHello 

<- ServerHello 
<- Certificate 

ServerHelloDone 

30 Certificate -> 
CUentKeyExchange 

ChangeCipherSpec -> 
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Finished 



ClientAutfaResponse 
5 (z.B. Passwort o. PIN) 



10 



ChangeCipherSpec 
Finished 



ChangeCipherSpec 
ClientAufhRequest 



modifizierter 

ServerMasterKeyExchange 
IP-Mnlticast-Adresse 
IP-MuIticast-Schlxissel 

ChangeCipherSpec 

Finished 



IS Hier geht der modifizierten ServerMasterKeyExchange-Nachricht ein ClieatAuthRequest 
des S^ers voraus. Mit diesem ClientAufhRequest ergeht die Aufforderung, die 
Aulhentisierung durch Emgabe beispielsweise eines Passworts oder einer PIN am Client 
vorzunehmen. Das Passwort bzw. die PIN werden vom Clieat mit der 
ClieatAuthResponse-Nachricht an den Server ubermittelt Der weitere Ablauf gestaltet 

20 sich entsprechend der zuvor dargestellten Verfahrensvariante. 

Beim Einsatz eines der zuvor beschriebenen modifizierten SSL-ProtokoUe zur 
Etablierung einer Security Association im Siime eines IPSec-Standards ist noch zu 
beachten, dass die einzelnen Nachrichten bzw. Nachrichtenblocke als ISAKMP- 
Nachrichten xibertragen werden (IETF RFC 2408) und dass die 

25 S^erMasterKeyExchange-Nachricht in alien Varianten neben dem (Pre-)MasterSecret 
auch alle anderen Informationen enthalt, um es dem Client zu erlauben, eine Security 
Association fur TP Multicast zu generieren (vgl. IETF RFC 2401). Dazu zahlen xmter 
anderem die IP Multicast-Adresse und der Security Parameters Index (SPI), der hier vom 
Server gesetzt werden muss. Security Associations sind bidirektional bzw. in beide 

30 Richtungen (Senden und Empfangen) gleich. 

Das SSL/TLS-ProtokoU wird heute auf OSI-Layer 2 oder 5 eingesetzt. Da das 
IP Protokoll und damit je nach Option das IP Multicast auf Layer 3 eingesetzt wird, kann 
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die Erfindung genauso wie das Standard SSL-Protokoll zwischen der Anwendungsschicht 
(Telnet, FTP oder HTTP) imd der Transportsdiicht TCP eingesetzt werden. 
Zur praktischen Realisi^ung des Verfahrens beantragt der Kunde ein spezielles SSL- 
Client-Zertifikat. In diesem Zertifikat ist eine Extension gesetzt, die anzeigt, dass dieses 
S Zertifikat zur Entschlusselung von Daten eingesetzt werden kann und vom Typ Multicast- 
SSL ist Mit dem Senden der jeweiligen Nacihrichten konnen zwar zwischen Client und 
Server auch, wie ublich, Random- Werte (ClientRandom, ServerRandom) ausgetauscht 
werden, jedoch gehen dieses nicht in die Berechnung des MasterKey bzw. des 
MasterSecret ein. Der MasterKey wird vom Server aussdblieBlich aus dem generierten 
10 PremasterSecret abgeldtet. 
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Patentanspruche 

1. Verfahren zur Schlusselvereinbanmg fur eine kryptographisdi gesicherte 
5 Pimkt-zu-Multipuiiktverbindung zwisch^ einer Datenquelle (Serv^) imd mehrerea 
Datensenken (Clients) im Internet, bei dem die Sdblusselvereinbarung nach einem 
modifizierten SSLr bzw. TLS-Protokoll erfolgt, wobei in Abhangigkeit eines in einer 
Server-Nachricht entbaltenen Kennzeichens, welches die au&ubauende Verbindung 
als IP Multicast- Verbindung kennzeichnet, die Reihenfolge der Nachrichten des die 
10 SSL-Sitzung einleitmden Handshakes verandert und der zur Etzeugung des oder der 
Sitzungsschliissel zur Verschlusselung der Anwendungsdaten dienende MasterKey 
vom Server generiert sowie gegebenenfalls mit dem offentlichen Schlussel des Clients 
verschliisselt an letzteren iibertragen wird. 

15 2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass das zur Kennzeichnung 
der Verbindung als TP Multicast-Verbindung dienende Kennzdchen (IP Multicast- 
Kennzeichen) Bestandteil des vom Server mit der CertificateRequest-Nachricht 
angeforderten ClientCertificateType ist. 

20 3. Verfahren nach Anspruch I, dadurch gekennzeichnet, dass das DPMuWcast- 
Kennzeichen Bestandteil einer modifizierten ServerMasterKeyExchange-Nachricht 
ist, mit welcher der Server gleichzeitig den MasterKey fur die spatere Ableitung von 
Sitzungsschlusseln an den Client iibermittelt. 

25 4. Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass die Reihenfolge der 
Nachrichten des die SSL-Sitzung einleitenden Handshakes, nachdem der Client eine 
mit dem IP Multicast-Kennzeichen versehene CertificateRequest-Nachricht vom 
Server empfangen hat, in der Wdse verandert wird, dass die Graerierung des 
MasterKey durch den Client unterbleibt, der Client sdn Certificate ohne unmittelbar 

30 anschliefiendes Senden einer ChangeCipherSpec-Nachricht und Umschalten auf 
verschlusselte Ubertragung an den Server iibertragt und der Server hierauf einen von 
ihm generierten und mit dem offentlichen Schlussel des Clients verschlusselten 
MasterKey mit einer ServerMasterKeyExchange-Nachricht an den Client iibermittelt. 
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wobei nach der Ubennittlung der ServerMasterKeyExdiange-Nachricht zunachst der 
Server nach Ausgabe von ChangeCipherSpec und Finished in den Modus fur eine 
verschlusselte Datenubotragung sdialtet und der Client die vom Server erhaltene 
ServerMasterKeyExchange-Nachricht daran anschliefiend durch Ausgabe von 
S ChangeCipherSpec und Finished sowie Umschalten in dca Modus iur die 
verschlusselte Ubertragung von Daten quittiert. 

5. Verfahren nach Anspruch 2 oder 3, dadurch gekennzeichnet, dass der Ablauf des 
Handshakes bis zur ChangeCipherSpec-Nachricht des Servers dem Handshake nach 

10 dem Standard-SSL-ProtokoU folgt, der Server aber dann anstelle der Finished- 
Nachricht erne modifizierte ServerMasterKeyExchange-Nachricht ausgibt, welche 
zumindest einen von ihm generierten verschliisselten MasterKey enthalt und von einer 
weiteren ChangeCipherSpec-Nachricht des Servers gefolgt wird, wobei der Client als 
Quittung ffir den Empfang des MasterKey und der nachfolgradra ChangeCipherSpec- 

15 Nachricht des Servers seinerseits emeut eine ChangeCipherSpec-Nachricht und eine 
Finished-Nachrticht ausgibt und danach in einen Verschlusselungsmodus umschaltet, 
bei dem der neue vom Server bereitgestellte MasterKey verwendet wird. 

6, Verfahren nach Anspruch 5, dadurch gekennzeichnet, dass der modifizierten 
20 ServerMasterKeyExchange-Nachricht eine CliratAuthRequest-Nachricht des Servers, 

mit welcher dieser den Client zur Autiientifizierung voizugsweise nut dnem Passwort 
oder einer PIN auffordert, sowie eine diese Aufforderung quittierende 
ClientAuthResponse-Nachricht des Clients vorausgehen. 

25 7. Verfahren nach einem der Anspruche 1 bis 6, dadurch gekennzeichnet, dass der 
Server in der Kommunikation mit einem Client innerhalb der ServerHello-Nachricht 
eine zur Koimntmikation mit anderen Clients identische CipherSuite verwendet, 
wobei fur den Fall, dass eine solche CipherSuite nicht ebenfalls in der 
ClientHello-Nachricht enthalten ist, vom Server eine Fehlermeldung ausgegeben 

30 wird. 

8. Verfahrm nach Anspruch 5 oder 6, dadurch gekennzeichnet, dass der Server und der 
Client nach der Ausgabe der jeweils zweiten ChangeCipherSpec-Nachricht zur 
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Verschlusselung die gleiche CipherSuite verwend^ auf die sie sich bei der 
Einldtung des Handshake mit d^ ClientHello-Nachrtidit und der ServerHello- 
Nachricht verstandigt habea. 
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ChangeCipherSpec 
Finished 



